Conversation
…IResolverRegistry
… a port during start-up
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2641 +/- ##
========================================
- Coverage 46% 46% -1%
+ Complexity 6737 6736 -1
========================================
Files 794 814 +20
Lines 65923 66406 +483
Branches 9888 9927 +39
========================================
- Hits 30858 30857 -1
- Misses 32684 33156 +472
- Partials 2381 2393 +12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
toinehartman
left a comment
There was a problem hiding this comment.
All of this (and the companion PR usethesource/rascal-language-servers#967) look like a nice unification and clean-up of interfaces.
src/org/rascalmpl/uri/remote/RemoteExternalResolverRegistry.java
Outdated
Show resolved
Hide resolved
DavyLandman
left a comment
There was a problem hiding this comment.
It's making progress, but it's not there yet.
src/org/rascalmpl/uri/remote/RemoteExternalResolverRegistry.java
Outdated
Show resolved
Hide resolved
src/org/rascalmpl/uri/remote/RemoteExternalResolverRegistry.java
Outdated
Show resolved
Hide resolved
src/org/rascalmpl/uri/remote/RemoteExternalResolverRegistry.java
Outdated
Show resolved
Hide resolved
src/org/rascalmpl/uri/remote/RemoteExternalResolverRegistry.java
Outdated
Show resolved
Hide resolved
src/org/rascalmpl/uri/remote/RemoteExternalResolverRegistry.java
Outdated
Show resolved
Hide resolved
src/org/rascalmpl/uri/remote/RemoteExternalResolverRegistry.java
Outdated
Show resolved
Hide resolved
…nted it in RascalFileSystemServices
…Type and aligned uses of the interfaces
|
| } | ||
|
|
||
| @Override | ||
| public CompletableFuture<FileWithType[]> list(ISourceLocationRequest req) { |
There was a problem hiding this comment.
this is the only method that doesn't follow the URIInputResolver style of listing entries. I think this is because of VS Code that wants this information? but we should document this in the interface definition why we took this detour.
There was a problem hiding this comment.
Yes, that's indeed what VS Code expects. Alternatively, we could do this the Rascal way (provide names only, no isDirectory boolean) and manually iterate over the listing with from the TS side
| var data = (JsonPrimitive) error.getData(); | ||
| if (data.isString()) { | ||
| switch (data.getAsString()) { | ||
| case "FileExists": // fall-through | ||
| case "EntryExists": | ||
| return new FileAlreadyExistsException(error.getMessage()); | ||
| case "FileNotFound": // fall-through | ||
| case "EntryNotFound": | ||
| return new NoSuchFileException(error.getMessage()); | ||
| case "FileNotADirectory": // fall-through | ||
| case "EntryNotADirectory": | ||
| return new NotDirectoryException(error.getMessage()); | ||
| case "FileIsADirectory": // fall-through | ||
| case "EntryIsADirectory": | ||
| return new IOException("File is a directory: " + error.getMessage()); | ||
| case "NoPermissions": | ||
| return new AccessDeniedException(error.getMessage()); |
There was a problem hiding this comment.
I think we should move this strings & matching to VS Code, and have extra numeric cases that our interfaces enforces? Such that we have dedicated error codes.
Also, shouldn't those error codes be part of the contract instead of private numbers? Like an enum somewhere?
I'm thinking of the next implementation of the VFS, like for neovim for example, how much is documented, and how much is VS Code specific. The goal is to have the least amount of VS Code details leak into our design.
| case JsonRpcErrorCode_NativeRascal: | ||
| return new IOException("Rascal native schemes should not be forwarded"); | ||
| default: | ||
| return new IOException("Missing case for: " + error); |
There was a problem hiding this comment.
I think we should say: "unkown IO exception: " + error + " data: "+ error.getData()



Closes #2701